Bitcoin timelock

TO read

input や output ではなく、transaction のフィールド

size は 4 bytes

Hex では8桁

有効になる場合とならない場合がある

有効な場合は、block に含めることができる最短の時間を表現している

UNIX timestamp か Block height で指定される

500_000_000 以上だと timestamp

nLockTime はある transaction をブロックに入れることができるタイミングを指定しているだけ。nLockTime が指定された tx が unlock しようとしている output を、他の tx がより早く unlock してしまう可能性がある。これを防ぎたい場合は、後述の方法により output 自体を lock する必要がある。

この制約が CLTV(BIP65)のモチベーションになっている

Miner は時間について嘘をつけるので、miner が指定する block time ではなくて過去11ブロックの block time の中央値を使う

マイナーが正直に blocktime を指定しているとしても、nLocktime に指定した UNIX timestamp よりも遅くなる、よね？

仮に6ブロック目が中央値だったなら、現時点でのブロックに含めることができるのは、およそ1時間前を nLockTime に指定している tx

ざっくりnLockTime に指定した時間の一時間後にはブロックに入る

locking script で記述される OP code

nLockTime だけでは実現できない UTXO の使用を制限することができる

CLTV で lock されている output を unlock するには、nLockTime が CLTV に与えられている値より大きくないといけない

たとえば、height 3000 まで CLTV でロックされているとする

unlock する tx の nLockTime は 3000 以上でないといけない

いま height が 2000 だとすると、nLockTime に 3000 を指定しても mining されない。それが nLockTime の定義。

height が 3000 になると、nLockTime に 3000 を指定した tx はブロックに入る可能性がある

絶対値?

nSequence による relative timelock

input に指定する nSequence によって、input が spent する output が block に含まれてからどのくらい経たないといけないかを指定する

spending tx の nSequence が locking script の CSV に与えられた値以上でないと fail する